【レポート】AWS Summit Tokyo 2017: PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 #AWSSummit

AWS Summit Tokyo 2017

#イベントレポート

#レポート

#AWS

2017.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

aws-summit-tokyo-2017-longlogo

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪品川プリンスホテルアネックスタワーで開催されています。

当エントリではDay3の導入事例トラックから「PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例」をレポートしたいと思います。

AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー：坂東聖博株式会社ソニー・インタラクティブエンタテインメントシステム/ネットワークエンジニアリング&オペレーション部門 NPS運用部システムオペレーション課セッション概要： 2006 年にサービスが開始された PlayStation™Network ですが、当初はもちろん全てのサービスがオンプレミス環境で稼働していました。現在でもまだ多くのサービスがオンプレミスで稼働していますが、本講演ではその中の 1 機能「Friendlist」について、MySQL から Amazon DynamoDB へのリプレイスを含む移行の手法について運用の観点からご紹介します。

セッションレポート

以下、セッションのレポートです。

本セッションの内容

PSNのFriend ListサービスをオンプレからAWSへ無停止で移行した
オンプレでの課題
AWSでどんな構成に
何かおきたか
教訓
規模感

アジェンダ

Play Station Network
FriendListについて
オンプレ版の問題
AWS移行を決めるまで
AWS上のFriendListについて
まとめ

Play Station Network

Play Stationのためのオンラインサービス
Store
- 会社のブラウザでゲームを買ったら、ウチの本体に来るとか
Plus
- 月額500円でゲームができる
Now
- 対戦、パーティーチャットなど

開発運用体制

世界3拠点
San Diego
- アカウントコマース
San Francisco
- ストア、ソーシャル
東京
- ゲーム、ソーシャル

東京チームの担当

プロファイル
イベント／トーナメント
トロフィー
フレンド

PS4の発売からネットワークがより多く使われる傾向に

CDN配信量が増加
毎年11-12月に大きく伸びる
トラフィック15Tbps
Monthly Active User 7000万人
延週利用時間 6億時間
- CloudFront使っている

FriendLlistについて

いわゆるお友達リスト
オンラインステータス、遊んでいるゲームなどを参照可能に
PS4で上限2000人
ブロックリスト、プライバシー設定
様々な機能から参照される
トロフィーの取得状況など

Friend Listシステムへのアクセス

基本的に他のサービスから間接的にアクセスされる
PSNのユーザエクスペリエンスに直結
かなりヘビーに使われる
- 落ちた時ツイッターで死ねとか言われる

オンプレ版構成

LB+フロント4台で1セット
- 24GB
- httpd,tomcat,memcached
更新系DB
- CPU Xeon E5 2.6G x2
- MySQL
- 256G
- ユーザ国別に3分割
- 350GB ２億ユーザ
リード系を別途用意
リード系とフロントは上記3セットをDNSラウンドロビン

Friend Listの歩み

2006/11 PS3発売 PSNの運用開始
2010/03 高負荷のためフレンド機能をFriend Listとして別システムから独立
2011/9 memcached導入
2011/12 PSVita
2013/9 フロントリプレイス
2013/11 PS4発売　FriendListの上限が100から2000人に増大
2014/4 DBリプレイス

Friend Listの問題点

スケールの難易度の高さ
メモリの上限256GBに限界
スケール速度の遅さ
機材の物理調達だけで数ヶ月
障害時の復旧の遅さ
レプリケーション

AWS移行の決断、経緯追加要件

2016/2 トランザクション数とメモリ利用率が増大、リプレイスしたものの限界が見えてくる
2017後半にTokyoオンプレ環境クローズの判断がされていた。リソース限界前にAWS環境に移行することを決定
PS4向けのサービスがAWSで稼働しており3000以上のインスタンスが稼働
PS4向けにDeploy Platformを構築済みだった

要求

ビジネス上
- ダウンタイムを短く
- 万一に備えてロールバック可能な
- 将来のマルチリージョンを見越した構成に
デベロッパ
- DBのプライマリキーを揃えたい(過去の経緯)
- アプリは新規で作り直したい
オペレーション
- DBはマネージドサービスを使いたい
- 8月後の2016/10には終わらせたい　11/12月に負荷が上がる

移行プロジェクト

2016/10まで
DBのPrimary Keyをconvertしながら
アプリは新規作成
この時点で2016/2

構成、ミドルウェア

フロント
- ELB+EC2 c3.2xlarge apache
DynamoDB
- ElastiCache Redis 2系
Auroraを使わないのはなぜ
- いろいろ検討。マルチAZやリカバリタイムがポイント。
Redis採用の理由
- 2系を採用
- 将来の追加。ロック機能を使いたい

3ステップで移行

ダンプ、変換アプリ、データを配置
シンクロナイザ SNS+SQS
最後切り替え

移行における前提

writeとreadがFQDNが別だった
ステータスファイルを参照
- メンテナンスモード時はアクセスしない
旧システムに更新時にSNSにPublishを追加
- ↑ただ一つ追加した機能

切り替えの進行

最初は全アクセスが旧システムに向いた状態
SNS Publish機能を有効化
- 更新がSQSに貯まる
- 14日以内にSQSの中身を処理せねばならない
DBからCSVでダンプを取る
- その後に発生した更新はSQSにある
CSVをDynamoDBに格納
- Primary Keyの変換もやる
シンクロナイザを使ってSQSのメッセージを新システムのDynamoDBに適用
- Primary Keyの変換も実施
- 1.5億件。空になるまで14時間かかった。開始したのが13日目でギリギリだった
トラブル
- コンバータの変換が途中で止まったりした
  - メモリを喰らい尽くす
  - スレッドがロックを取り合う
- PK変換がうまくいかないユーザがいる
  - 実装を修正して再実施
- サービスに影響を与えることなくリトライができる環境が重要だった
参照系アクセスの一部を新アクセスに向ける
- シンクロナイザのラグは数秒〜20秒
全リードアクセスを新しい方へ向ける
- Dynamoのキャパシティが超えていないか確認しつつ
- Redisのスワップ使用量が増加
  - 切り戻してreserved memoryを確保、対策した
ラグが許されないサービスのみ残してほとんどのリードを向ける
Write系の切り替えのためメンテナンスモードに入れる
旧サーバを停止
メンテナンスモードを解除
- 更新アクセスも新サーバで処理開始